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Dependency - progress of one action relies upon the 
timely output of a previous action, or the presence of 
some specific thing. 





From: Strode, D.E. and Huff, S.L. A 
taxonomy of dependencies in agile 
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A Taxonomy of Dependencies in Agile Software Development 
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School of Information Management 
Victoria University of Wellington 
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Abstract 


Dependencies in a software project can contribute to unsatisfactory progress if they constrain or block the flow 
of work. Various studies highlight the importance of dependencies in the organisation of work; however 
dependencies in agile software development projects have not previously been a research focus. Drawing on 
three case studies of agile software projects, and the IS literature, this paper develops an initial taxonomy of 
agile software project dependencies. Three distinct categories of dependency are found: task, resource, and 
knowledge dependencies. This paper contributes to theory by providing a taxonomy of dependency types 
occurring in the area of agile software development. Practitioners can use this taxonomy as sensitising device 
to ensure they consider dependencies they might face that could hinder their projects, enabling them to take 
appropriate and timely mitigating action. 
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Agile software development, Dependency analysis, Dependency Taxonomy, Software project dependencies. 
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Taxonomy of Agile Software Project Dependencies 
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Figure 1: A taxonomy of dependencies in agile software development projects 
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Increased lead-time of work items 


Causes friction between teams who have _ 
different priorities and rewards 
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REDUCED FREEDOM IN ORDERING WORK ITEMS 








The Effects of Team Backlog Dependencies on Agile Multiteam Systems: 
A Graph Theoretical Approach 
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Abstract 


Jn agile software development, the prioritization of 
backlog items is the mission-critical responsibility of 


the product owners in order to maximize the customer 
value created by development teams. However, in the 
reality of large-scale development, the degree of free- 
dom for such a prioritization is substantially restricted 
by various types of inferdependencies between backlog 
items. In this work, we show, using a graph theoretical 
approach, the relation between the degree of freedom 
for prioritization and the occurrence of dependencies. 


To the best of our knowledge, the breadth and depth of 


such consequences has never been modeled or investi- 
gated up until now. Based on our results, we derive 
implications for real-world large-scale software devel- 
opment in agile environments. 
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dependencies to allow for effective multiteam system 
coordination and efficient intra-team work [45]. Yet, in 
real-world examples of large-scale agile development 
environments, product owners are often complaining 
about being responsible for prioritizing requirements 
and creating value for customers, while the stage 1s 
already set due to given dependencies. As described in 
the Scaled Agile Framework (SAFe) by Leffingwell 
[26], cross-team features in the shared program back- 
log are split into single-team backlog items, 1-e. user 
stories, with tentative allocations to individual sprints, 
which limits the product owners and their teams in 
their “free choice” of backlog item prioritization. 
According to the agile development paradigm, 
Maximizing customer value and thus ensuring econom- 
i¢ product viability for the company 1s a key principle 
3 SI. Nevertheless. products. are rarely aut _from_ 
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ingly, an mcreased amount of dependencies dramati- 
cally lowers the Dc - This confirms our imitial expecta- 
tion in chapter 2.2, that predetermined dependencies 
have a significant impact on the pnoritization ability of 
the team product owner. In fact, the product owner 15 

drastically hmuted im freely assigning priorities to the 
g backlog items and subsequently ordering them accord- 
a ingly. One dependency between two backlog items, for 
example, will already reduce his freedom of choice in 
how to prioritize the ores by Sa. 
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5 Features. 

No Dependencies. 
120 unique 
ordering options. 
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5 Features. 

1 Dependency. 
60 unique 
ordering options. 
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5 Features. 

2 Dependencies. 
20 unique 
ordering options. 
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INCREASED LEAD TIME 
OF WORK ITEMS 
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Average Flight Delay 


By cause and scheduled hour of departure 
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Four people arrange a 
restaurant booking after work 


Q. What is the chance they 
arrive on-time to be seated? 
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Team Dependency Diagram 


Diagram thanks to Dan Greening 


@t_magennis (@greening) of SenexRex. 
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Time = (Optimistic + 4 x Most likely + Pessimistic) / 6 





Delays are NOT CAUSED by the 
item being delayed, its caused by 
other factors that are unknowable 
(and unquantifiable) in advance. 





It’s the start time we struggle to compute, 
PERT worries about the completion time. 
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Estimate = Sum Sprints x 1.5 


If all work 1 sprint: 
7X2x1.5 =21 weeks 
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— Se ee ee 50% teams will miss 
the expected time. 








Team Dependency Diagram 


34 Diagram thanks to Dan Greening 
@greening) of SenexRex. 
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What causes so many small teams? 








"The Magical Number 
seven, Plus or Minus 
Two: Some Limits on 
Our Capacity for 
macele-s-s-y ale ialiolauit-lire)am 


George A Miller — Miller’s Law 














Number of links between people = n x (n-1) / 2 


1400 
1200 
1000 
800 
600 
400 
200 
0 


Number of links between people 





2 6 12 24 50 
Number of people (team size = n) 


RFORMANCE 


relationship to perforr 


Predictability @ Responsiveness 








relationship to perform 


Worse 


elationship to perforn 





9-15 





Responsiveness 


elationsnip to perfor 


Better 


redictability 


relationship to perfort 


~ Equal 


|| 
ff 








1. Team Performance > System Perf. 
2. Performance > Predictability 
3. Team co-ordination cost is low 


Keep team 
size smaller if... 











Consider up to 15 ppl if it 
decreases a dependency 
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Reducing Dependencies: Team Structure Options 


Create multi-disciplined 
Merge teams feature teams Co-locate teams who 
depend on each other 
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1. Merge 
2. Co-Locate 


Team Dependency Diagram 





A7 Diagram thanks to Dan Greening 
(@greening) of SenexRex. 
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Matrix — Component vs Feature 
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Component Team Feature Team 








Legend 


Component or Skillset Area Teams 


Pros Team 1 


A 


Team 3 
¢ Consistent practices 


¢ Predictable in isolation 
¢ Complete area knowledge 
¢ Fast ramp-up of new members 





Cons 

¢ Many dependencies A 
¢ Low predictability as a system 

¢ No system understanding _ 
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Pros 

¢ Few/Any Dependencies 

¢ Predictable feature delivery 
¢ Complete feature knowledge 


Cons 
¢ Divergent practices 


¢ Code / build Integration harder 


¢ Beware of single “expert” 


Feature Teams 


Team 2 


Team 1 
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Planning and Growing Teams 


¢ Skill falls into levels | way 
1. Can teach others Train or Plan 
Hire Skills 


2. Cando 


3. Have the desire 
4. No idea, and never will! 


¢ Continuous Cycle 
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Growing Teams — Skills != People 
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Skill Assessment — Knowing and Growing 


Download from: Bit.ly/SimResources (Spreadsheets, Capability Matrix.xlsx) 
Capability Survey For Printing (enter skills in the Settings worksheet) 
Team Name: Your Name: 


For each capability choose from the list of CURRENT skill level values. If in doubt, err low (left)! 


ones and 


create 
CSS 
Javascript 
DB Backup/Restore 





For each skill, choose from the list of DESIREABLE values. If in doubt, err high (right)! 


I'd quit rather | Actively Avoid, Strongly 
than do this... | unless coerced... | Willing to learn Interested 
CSS 
Javascript 
DB Backup/Restore 





- B C | D 








































1 | css _avascript DB Backup/Restore 

< |Person1 ‘Can run and use the tools r a Know nothing Can run and use the tools neede 
3 |Person ? <now nothing * \nstart from nothing and create |Can tweak it or do easy bug 

A Team 1 Know nothing " 

: Can run and use the tools needed 

14 | Can start from nothing and create 


Expert level 


15 | Analysis: 











| Javascript __—=—— | DB Backup/Restore 
17 Teach & Create 
18 Do & Maintain ) 


19 |Novice & Learner 














21 General guidelines: 0 = bad, 1 = single point of failure, >2 cool! 








23 _ Teach & Create: These are the people/teams who can create new work and teach others. You need at least one (right?). Are you able to cope if that person i 
off sick or vacation? If not, then train up a maintainer or bench employee? 


oi Do & Maintain: These are the people/teams who can maintain current work, but struggle to create new work. If new work isn't expected, it may be ok to 
__| have no captains but a crew of maintainers. Still, one seems too risky? Grow from the bench. 
“9 Novice & LEarner (bench): These are the people/teams who although haven't got this skill yet, have the tools required to perform this task if mentored or 





ef _ paired with a Player. If you have too few Captains and Players, you need to develop these urgently. 








Download from: Bit.ly/SimResources (Spreadsheets, Capability Matrix.xlsx) 
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CLEAR AND ALIGNED PRIORITIES 








Incentives 
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Thanks to Lisa Long and Chris 
Matts for the cookie analogy. 





Different players have different rewards. 






“Do a feature, 


get a cookie” 
~ Lisa Long 


lf rewards aren't 
aligned, different 
ordering decisions 
are made 





Home > Product Categories > Ungrouped > Automatic Cookies Aligning Machine With Chinese Supplier 


Automatic Cookies Aligning Machine Wit 








Min.Order Quantity: 1 Set/Sets 

Supply Ability: 20 Set/Sets per Month 

Port Shanghai 

Payment Terms: LIC D/A DIP T/T Western Unio 
MA | @® Chat Now 





StartOrder  \DaAddtoinquiryCart WrAddtoMy! 


This supplier supports Trade Assuran 

Follow the Trade Assurance process <¢ 

S eletia laine |. com : : , 

- setts ; « On-time shipment and pre-shipment produc 

« Refund up to the covered amount agreed wi 
_ Iie. 














Friendly 
Competition 
aligned with 

Desired 

Outcomes 


Incentives, even if light handed play a big role 


Feature1&5 
are prioritized 


Work released to prod 





Wrong order list 





Work released to prod 


Feature 1 
Feature 5 
Production Defect 
Feature 2 
Feature 3 
Feature 4 


Feature 6 


Thanks to Chris Matts, Lisa Long and John Horton for the “Wrong order’o’meter” concept. 





Take-Aways 


Be aware of the impact of dependencies 

— A single dependency reduce order options 50%, < 1% with 4 

— Every dependency removed double your chance of on-time delivery 
Don't be afraid to have teams up to 15 people 

— if it avoids even a single dependency 
Visualize your dependencies 

Manage your team skill balance to avoid constraints 


Get cookies aligned between teams and dependents 


Risk — The Final Enterprise Agile Frontier 





¢ Top 10 reasons forecasting software projects fails 
¢ Not your grandparents risk management 
¢ How and why to do agile risk management 


Risk — The Final Enterprise Agile Frontier 
10:45 — National Harbor 6/7 


Thank You 


Email me: troy.magennis@focusedobjective.com 


Follow me: @t_magennis 


Get spreadsheets and tools: htt 


Download the slides: [here] 
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